Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a navigation counter to Documents #7370

Closed
wants to merge 2 commits into from

Conversation

clelland
Copy link
Contributor

@clelland clelland commented Nov 25, 2021

@clelland
Copy link
Contributor Author

This is prerequisite work for w3c/performance-timeline#192 - tests and bugs are incoming; I'll update the description as those are completed.

@annevk
Copy link
Member

annevk commented Nov 26, 2021

This seems more like a bfcache counter? It would help to have a little more context for review.

@clelland
Copy link
Contributor Author

The idea is that there are several ways that a user can do something that is perceived as a 'navigation' that will not actually reset any state in the document. Currently, I can think of:

  • initial page load
  • restoration from session history (bfcache)
  • App history (SPA) navigation

There might be more, but these at least would increment this counter. The counter itself would be exposed in PerformanceEntry objects in the Performance Timeline. This allows consumers of that timeline to segment performance events by user navigation, and to understand the performance of the page in that context.

See w3c/performance-timeline#182 for more context, and w3c/performance-timeline#192 for the actual proposed integration there.

@annevk
Copy link
Member

annevk commented Nov 29, 2021

We should probably note that this can be a (limited) tracking vector and that it ought to be cleared when the user clears website data. (It's not entirely clear to me that would logically follow from bfcache or app history requirements, although it prolly should.)

@domenic
Copy link
Member

domenic commented Nov 29, 2021

Currently, I can think of:

I'm wondering why an app history navigation is treated specifically here, as opposed to a pushState() or replaceState(). The difference between the two is app history navigations have a clear duration, and an additional (async) success or failure signal. But IMO both should be counted as "navigations", and that is what https://github.com/WICG/app-history/#performance-timeline-api-integration envisions.

@domenic
Copy link
Member

domenic commented Nov 29, 2021

Alternately if the intent is really more of "how many times has pageshow been called", then I would change this to "pageshow counter" and change the corresponding performance API from navigationId to pageshowCounter or similar.

@clelland
Copy link
Contributor Author

I'm wondering why an app history navigation is treated specifically here, as opposed to a pushState() or replaceState()

pushState and replaceState and friends aren't a clear signal that the user would have perceived something like a navigation -- they are often used that way, but they're just as often used to update the address bar without any real 'transition' taking place. That's why we have the AppHistory API, and I think that we only want to count the declarative use of appHistory.navigate.

Alternately if the intent is really more of "how many times has pageshow been called"

Is pageshow fired on app history navigations? If so, thats' a possibility.

@domenic
Copy link
Member

domenic commented Nov 29, 2021

I think that's unfortunately based on a misunderstanding of the app history API. As I said, the only distinction between the two is a duration and async success/failure signal.

There's nothing special about navigations from appHistory.navigate(); appHistory.navigate() is just location.assign() with a few more options. You can override the behavior of location.assign() or appHistory.navigate() or history.pushState() using the navigate event listener to be a duration-having SPA nav. But doing so is agnostic to the source of navigation.

I think the only principled distinction you can make is between cross-document navigations and same-document navigations. Making a distinction based on what API people use is not something the current app history spec infrastructure supports, nor is it something I recommend.

Is pageshow fired on app history navigations? If so, thats' a possibility.

No.

@clelland
Copy link
Contributor Author

clelland commented Dec 3, 2021

My understanding of the AppHistory API is that it can do two things for us here:

  1. It exposes a difference between script-initiated and user-initiated history state transitions
  2. It provides a new way to declare that a navigation transition has completed (with the resolution of the .navigate promise)

My goal is to capture, or rather to allow interested developers to capture the idea of user-visible navigation-like transitions, to be able to use that to reason about page performance. In some cases, these transitions are full-document reloads, in others they are bfcache restorations (which may be indistinguishable to the user from the first case, but don't change any document state), and in other cases, they are SPA navs (which don't load a different document, but may change significant page state).

Since there are a large number of sites which use the existing history API to record page state information without what the user would see as a 'navigation', I don't know if we can tie this counter to that API. However, the fact that the AppHistory API provides an explicit navigation signal (especially with the 'user-initiated' concept,) it seems that we could leverage that to give developers the option to have those marked as 'navigations' in the performance timeline, by hooking those events up to this counter.

Should this discussion be moved to https://github.com/WICG/app-history/issues?

@domenic
Copy link
Member

domenic commented Dec 3, 2021

Right, I'm saying this is not a correct impression. userInitiated applies to all navigations causes by clicking on links or submitting forms, and to zero navigations caused by navigate(). And all navigations can have duration once you use app history, including pushState() ones.

I'm OK with any venue for discussion.

@clelland
Copy link
Contributor Author

clelland commented Oct 3, 2022

Coming back to this: Tying to the Navigation API, as @domenic says, is probably not possible.

I'm fine with any naming that folks think make sense.

The intention is to collect "user-perceived" navigation transitions. Updates to state which are effectively the same to a user as a back or forward navigation, but which don't actually create a new browsing context, should update this member.

Initially, this should tie into back-forward-cache restorations, and Chrome would like to use this to expose SPA transitions through https://bit.ly/soft-navigation heuristics, hence the more inclusive proposed name.

@domenic
Copy link
Member

domenic commented Oct 4, 2022

I still find the current state, and eventual desired end state, confusing. I re-read the two threads you linked above but between them I think I see about 4 possible proposals floating around. Is there an explainer available?

@clelland
Copy link
Contributor Author

clelland commented Nov 7, 2022

I've written up a short motivation, and the concrete proposal, here: https://github.com/clelland/navigationId

@annevk
Copy link
Member

annevk commented Nov 10, 2022

Where is the concrete proposal? I'm afraid that "An SPA navigation is detected" isn't something that makes normative sense.

@clelland
Copy link
Contributor Author

@yoavweiss is working on a way to specify that precisely; the latest work is at https://github.com/yoavweiss/soft-navigations/, which is now linked.

The heuristics there would be used to trigger a new SoftNavigation performance entry in the performance timeline. Like a back-forward cache restoration, this SPA navigation would update the navigationId to a new value, and include that value in the SoftNavigation entry in the timeline. Subsequent timeline events, up until the next cache restoration or SPA nav, would reference that new navigationId.

@domenic
Copy link
Member

domenic commented Nov 16, 2022

This design seems reasonable to me. I wish it didn't use the phrase "navigation ID", since we're already using that for a spec-level concept that identifies actual navigations in the sense of the navigate <dfn>. But I don't have any better ideas, and web developers have priority.

@clelland
Copy link
Contributor Author

I think that this can be done differently, entirely within the Performance Timeline API with less intrusion into HTML's navigation algorithms. I've updated w3c/performance-timeline#192, and I'll close this for now.

@clelland clelland closed this Jul 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants